> ... the CE (chip enable) pin?

CE (chip enable), CS (chip select), SS (slave select) are all usually
synonymous.

Yes, although it is active-high, not active-low, which is the convention
in my experience - and what the BX-24 expects.  You'll need, then, to
invert \CS from the processor.

You can use any inverting logic device like a 74n04, or a transistor
configured as an inverter (typically two resistors and an NPN but, since
the CE pin has an internal pulldown, just a single base resistor on a
PNP, emitter to Vcc, collector to CE, should also work), between the /CS
pin you select on the BX-24 and the CE input of the RTC.  You should
still put a pullup resistor between your selected /CS pin and Vcc to
avoid the Reset concern.


Tom

> ... add a transitor whith the base connected to a GPIO port and put
the voltage divider on the colector side...

As it happens, I am just finishing a battery state-of-charge monitoring
and switching device.  I've found that a voltage divider of 100k over
220k provides a good range for 12v applications, yielding 5v at the tap
for a 16v sense.  Unless your device needs to be low-power, perhaps
operated from its own primary battery and using processor power-down
mode, switching the voltage divider current is not necessary - and it
probably reduces the voltage at the top of the divider, adding some
inaccuracy to be corrected.

Also, for _under-load_ battery voltage measurements to be accurate and
revelent, it might be necessary to measure differentially - at both
battery posts, not just the positive post, subtracting the measurements
- to avoid false indications due to voltage drop in the battery ground
lead.  And, if you are trying to judge the battery state when _not_
under load, charging voltage might conceal the battery condition.  Since
UPSs often do periodic self-testing (but usually without switching the
AC load), it might be possible to sense battery droop during that brief
test period and make your battery-condition judgment then.

If the processor is remoted from the battery location, the loss in the
cabling between them can become important, particularly if the processor
is powered by the battery, due to voltage drop, again, in the ground
line due to current drawn by the processor itself.  It might be
necessary to also measure a stable voltage reference - perhaps a 78L05,
placed at the battery end - to use to correct the apparent voltages at
the processor end of the cable; this can be a significant error if not
corrected.  If the processor is at the battery end, it is not an issue.

I'm using an LCD-X for this project - a perfect fit in my situation.
http://rightime.com/images/DSCN0133.JPG As long as it is active, you can
see it in live testing here: http://www.ustream.tv/channel/hydralight


Tom

Patrick,
USB requires a stack and other software and each device has a unique
identifier.  So unless someone has written some code to handle it I think
you will need to just use an off the shelf solution such as the ones
suggested.  Once the I/O has been converted to strait serial you should be
able to do whatever you need with it.
Harry


   _____

From: basicx@yahoogroups.com [mailto:basicx@yahoogroups.com] On Behalf Of
Patrick
Sent: Wednesday, October 28, 2009 6:27 PM
To: basicx@yahoogroups.com
Subject: [BasicX] Re: USB Communication with the BasicX




Hello,

Thanks to all of you who have reply to my message.

I am not looking for an USB to RS232 converter or adaptor .

I am asking if it is possible with the BasicX to generate on one pin (or
more) a signal which is of the format of USB output directly or if the
Basicx can read an USB signal.
The basicx or Basic Stamp and other microcontroller can send data in the
RS232 format (TX) or read an RS232 input (RX) and I wanted to know if we can
do the same for an USB port, send a signal in USB format readable for
exemple by the USB port on the PC.and if the Basicx can "decode" a signal
coming from my PC via the USB port.

Thanks for your feedback.

Best Regards.

Patrick.

--- In basicx@yahoogroups. <mailto:basicx%40yahoogroups.com> com, "Patrick"
<gouardopatrick@...> wrote:
>
> Hello Everybody,
>
> More and more PC home computer devices use USB connexion and less and less
the RS232 connexion is available.
>
> I like to know if the Basicx-24 can send, received and interpret USB data
and what command to use for these purposes.
>
> Thanks for your help by replying to my message and best regards.
>
> Patrick.
>








Dynatest Confidential
Note: This message and any attachment hereto is intended solely for the use of
the designated recipient(s) and their appointed delegates and may contain
confidential information. Any unauthorized use, disclosure, copying, or
distribution of its contents is strictly prohibited. If you have received this
message in error, please destroy it and advise the sender immediately by phone,
email, or fax. Thank you for your cooperation

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

Tom, problems that have been solved so far:
1-  Bx does not stuck anymore while downloading (since I put the pullup
resistor in CS pin)
2 - BX's CS is active low. I'm now communicating with max146, which is
also active low, so no need to invert logic using a transistor or a 74N04.

I'm trying to communicate with max146 instead of DS1305 because I'm more
familiar with it...
Now the problem is that I only receive bytes containing zeros...

My code is:

dim sent_bytes(1 to 3)as byte
dim received_bytes(1 to 3) as byte
sent_bytes(1)=bx1000_1111
sent_bytes(2)=bx0000_0000
sent_bytes(3)=bx0000_0000
do
     Call SPICmd(1,3,sent_bytes,3,received_bytes)
     debug.print "1º:"; CStr(received_bytes(1))
     debug.print "2º:"; CStr(received_bytes(2))
     debug.print "3º:"; CStr(received_bytes(3))
     call delay (1.0)
loop

Any ideas?
How should I configure the initial state of CS pin? Tristate, Pullup,
Output_low, Output_high?
Thanx again for your help

David M.

No OpenSPI()?  The specified /CS pin will be automatically configured by it.

Tom

> dim sent_bytes(1 to 3)as byte
> dim received_bytes(1 to 3) as byte
> sent_bytes(1)=bx1000_1111
> sent_bytes(2)=bx0000_0000
> sent_bytes(3)=bx0000_0000
> do
>     Call SPICmd(1,3,sent_bytes,3,received_bytes)
>     debug.print "1º:"; CStr(received_bytes(1))
>     debug.print "2º:"; CStr(received_bytes(2))
>     debug.print "3º:"; CStr(received_bytes(3))
>     call delay (1.0)
> loop
>

Sorry, Tom, didn't give you all the code to make it simpler...
here goes:

Option Explicit
public Channel As Byte

Public Sub Main()

     call abre_spi()
     call mede_ADC()


End Sub


'_______________________________________________________________________________\
___
Public sub mede_ADC()
dim sent_bytes(1 to 3)as byte
dim received_bytes(1 to 3) as byte


sent_bytes(1)=bx1000_1111 ' para channel 0
sent_bytes(2)=bx0000_0000
sent_bytes(3)=bx0000_0000



do
     Call SPICmd(1,3,sent_bytes,3,received_bytes)
     debug.print "1º:"; CStr(received_bytes(1))
     debug.print "2º:"; CStr(received_bytes(2))
     debug.print "3º:"; CStr(received_bytes(3))
     call delay (1.0)
loop

End sub




'_______________________________________________________________________________\
______
public sub abre_spi()
     Dim ChipSelectPin As Byte
     Dim LSBFirst As Boolean
     Dim ClockPolarity As Boolean
     Dim ClockPhase As Boolean


     Channel = 1
     ChipSelectPin = 13
     LSBFirst = False
     ClockPolarity = False
     ClockPhase = False


     Const SPIRateDiv4   As Byte = bx0000_0000   ' Clock speed = f/4
     Const SPIRateDiv16  As Byte = bx0000_0001   ' Clock speed = f/16
     Const SPIRateDiv64  As Byte = bx0000_0010   ' Clock speed = f/64
     Const SPIRateDiv128 As Byte = bx0000_0011   ' Clock speed = f/128
     Const ClockRateSelect As Byte= SPIRateDiv128


     ' See Atmel documentation for these bits.
     Const DORD As Byte = bx0010_0000   ' Data order, LSB first.
     Const CPOL As Byte = bx0000_1000   ' Clock polarity, SCK high when idle.
     Const CPHA As Byte = bx0000_0100   ' Clock phase.

     Dim SetupByte As Byte

     ' Safety clamp.
     If (Channel < 1) Then
         Channel = 1
     ElseIf (Channel > 4) Then
         Channel = 4
     End If

     SetupByte = ClockRateSelect

     If (LSBFirst) Then
         SetupByte = SetupByte Or DORD
     End If

     If (ClockPolarity) Then
         SetupByte = SetupByte Or CPOL
     End If

     If (ClockPhase) Then
         SetupByte = SetupByte Or CPHA
     End If

     Call OpenSPI(Channel, SetupByte, ChipSelectPin)


End sub

Looking quickly, I don't see an obvious problem.  I posted a simple
two-transistor SPI loopback drawing (actually, a tristate non-inverting
buffer, enabled by /CS, is simpler if you happen to have one) some time
ago.  The loopback should simply echo your sent data.  If it works, the
problem is probably with the device.

If this link doesn't work, look for it in
http://tech.groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Dra\
wings/Comm/SPI/SPI_Loopback.JPG
.

Tom

Hello
Eventough it still needs some tunning, I'm being able to receive
valuable data from the max146...
One question: how should the CS pin be configured? Tristate, Pullup,
Output_Low, Output_High?

Reg
David M.

And yet another question:
In my code:

Call SPICmd(1,1,sent_bytes(1),1,received_bytes(1))
Call SPICmd(1,1,sent_bytes(2),1,received_bytes(2))
Call SPICmd(1,1,sent_bytes(3),1,received_bytes(3))
debug.print CStr(received_bytes(1)) ; ";" ; CStr(received_bytes(2)); ";"
; CStr(received_bytes(3))

The result of the ADC conversion is being sent on the first 2 received
bytes whereas it should be sent on the last 2 received bytes...
Any ideas, on why this is happening?

Reg

David M.

> ... how should the CS pin be configured?

OpenSPI will configure the /CS pin high.  Its state before that should
be either untouched (since a processor Reset sets all pins to
InputTristate) or, if you like, you may set the pin to any state except
Low, which will likely cause the SPI device to interfere with code
execution.

Assuming you have an SPI device connected, with its /CS on pin 12, you
can test this easily:

Sub Main()
     call sleep(1.0)

     ' call PutPin(12, bxOutputLow) ' will probably crash the machine
here, no flashing LED

     call OpenSPI(1, 0, 12) ' pin 12 set high by Open

     do   ' flash LED
        call PutPin(25, bxOutputLow)
        call sleep(0.1)
        call PutPin(25, bxOutputHigh)
        call sleep(0.1)
     loop

End Sub


Tom

Thanx, Tom!
My next step is to try to configure the BX to communicate with max1302
via 3-wire protocol...
1 - What should I change on my pin configuration on the BX24 side?
2 - Should I still use OpenSPI and SPICmd commands?


Reg

David M.

> ... 1 - What should I change on my pin configuration on the BX24 side?
2 - Should I still use OpenSPI and SPICmd commands?

If, by "3-wire protocol" you mean SPI, if you are currently successful
with the max146, I see no reason to change anything except the data you
send to control the device, and the handling and interpretation of the
resulting data.

Tom

But on the max1302 side I only have the following pins for communication:
SCLK, I/O and CE
What should I connect to I/O? Both MISO and MOSI? Without external
components such as diodes or resistors?

David M.

> ... SCLK, I/O and CE...

Are we looking at the same part?

The Maxim Max1302 shows Din, Dout, SClk, and /CS.
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4746


Tom

No, sorry, the CORRECT part number is maxim's DS1302:
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2685

David M.

> ... DS1302...

Ah; you did say 3-wire and, you're right, that's not an SPI interface
device.  You'd have better success, I think, using ShiftIn() and
ShiftOut() with it.

Somewhere up the thread, you were talking about using a DS1305, which is
an SPI RTC.


Tom

Unfortunatly my DS1305 did not yet arrive and so I was trying to solve
my problem with a DS1302...
What is opinion?
1- Is it much hard work than with a SPI interface?
2 - DS1302 is LSB first whereas Shiftout command is MSB first... I would
need to do some bitwise operations, right?
3 - I would need to set the CE pin manually, right?

Thanks again for all your help
David M.

Yes, you'll need to control CE via PutPin().  On a quick read of the
DS1302 single-byte read/write specs, it looks like you need to raise CE,
then write a command byte then write a data byte for output to the
'1302, or write a command byte then read a data byte for input from the
'1302, then drop CE.

Reversing the bit order can be done in a simple loop, shifting one byte
value right while the other shifts left, or vice-versa.  You might find
that, since you apparently need to loop through the byte anyway, it
might be easier to just output (or input) the bit using PutPin() then,
rather than wait for a complete reversed byte to use ShiftOut() or
ShiftIn(); if you do that you'll also need to generate the clock pulse
with a pair of PutPin().  The data rate would be slower that way but, if
you want to, you can speed it up later once you have something working.


Tom

I'll give it a try...
Meanwhile I came across the function FlipBits that, apparently reverses
the bit order automatically...
Have you heard about it?

David

> ... FlipBits...

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


Tom

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.

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

> 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

yes, both pins are connected to IO pin of DS1302

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

> ... 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

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"

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

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]

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.