DS-1267 having trouble sending values

[cadillackid]

ok I have a DS-1267 digital pot connected to my ZX-328n for my HVAC project...

I have used these successfully with the basic stamp before.. but am having some trouble with the math to send the values to the POTS of it....

has anyone used one of these? it requires 17 bits of data... the first bit I just pulse out and that handles that... same way I did it on the basic stamp..

the next 16 are where im having issues.. if i want to set both pots at say value 100.. somehow i have to get the value 100 sent "twice" in a 16 bit value and thats where im getting lost here...

here is the code im trying to use (with some debugging in it to watch what I see)
in the basic stamp I would just put my desired value 0-255 into the high byte and the low byte of a "word" variable...

how do I do that in zbasic?
so if I wanted to set both values to "100"..

so anyone who may have better understanding please help..

Code: Select all

' *************************************************************
' sub routine to set the digital POT values
' *************************************************************
public sub setpot(byval num as integer)
call putqueuestr(oq,"sending data to pot:"+cstr((num*100)+num)+chr(13)+chr(10))
' bring up the reset line to high to begin the POT set.
call putpin(c.4,zxoutputhigh)

' send a blank pulse across DQ as we dont need the stack select feature
call pulseout(c.3,1,1)
' send out the data 1 bit at a time MSB first
call shiftoutex(c.5,c.3,16,cint((num*100)+num),0)

call putpin(c.4,zxoutputlow)

end sub

-Christopher

[mikep]

If num is a byte value between 0 and 255 then you should declare it as a byte. To create a 16-bit value from two 8 bit values the simplest function is to use MakeWord. Even if that didn't exist you should be multiplying by 256 (not 100).

I also fixed your string concatentation operator to be '&' instead of '+'. Try this code instead:

Code: Select all

public sub setpot(byval num as byte)
call putqueuestr(oq,"sending data to pot:" & CStrHex(makeword(num, num)) & chr(13) & chr(10))
'debug.print "sending data to pot:" & CStrHex(makeword(num, num)) & chr(13) & chr(10)

' bring up the reset line to high to begin the POT set.
call putpin(c.4,zxoutputhigh)

' send a blank pulse across DQ as we dont need the stack select feature
call pulseout(c.3,1,1)
' send out the data 1 bit at a time MSB first
call shiftoutex(c.5,c.3,16,makeword(num, num),0)

call putpin(c.4,zxoutputlow)

end sub

[cadillackid]

thanks for the help!.. not sure how i missed the Makeword function it kind of blares out... guess thats what I get for writing code when im tired (same as multiplying by 100... 100 was the test value i was using for my digital POT)..

a simple multiply by 256 did the job as does the makeword..

I noticed you added and commented out a debug.print statement.. should I be using that instead of sending and receiving data from my com port queue?

earlier I had a mixture of debug.print and outqueue in my program and it made a mess of things so I set it up to do any debugging through the queues... of course as I get closer to putting this thing in actual operation I wil be removing the debugging... or more likely I'll have a flag i can set that will turn the debugging on and off...

im still amazed at how much easier these zbasic devices are to work with than pics and picbasic...
-Christopher

[mikep]

I wasn't sure what you were using the queue for so I left it alone and added my own debugging statement for test purposes. Using queues versus debug.print for debugging is up to you but should be consistent.

I have used both before. Debug.print of course always sends its output to COM1. I used a queue one time when I wanted debug output to go to a software serial port (COM3) instead of COM1. I was using the hardware USART for high speed serial comms.

Using a queue requires a bit more work because as you have found you need to add your own CR/LF. It also tends to use strings and string concatenation more so be careful of your stack space. See application note AN-218 and the associated code module DebugPrint.bas which sends debug strings to either a hardware or software serial port.

Writing each part of the string separately to the queue may be faster and uses less stack space but is not task safe. You also need to add explicit conversions for numbers to strings such as CStr and CStrHex that are implicitly added by the compiler when using debug.print. Here is some example code:

Code: Select all

Public Const CRLF as String = Chr(&H0d)&Chr(&H0a)

call putqueuestr(oq,"sending data to pot:")
call putqueuestr(oq,CStrHex(makeword(num, num))
call putqueuestr(oq,CRLF)