Some one take a look at this and tell me if it's right

James Long

I took this directly out of the MAX_1270 file. The pub start and the·get_count parameters do not match. Is this common?

The reason I ask.....I do not see where the control & control_bit have any correlation. Nor the average & averag_sample.

This has been cracking my skull for at least two days. I have a max 1202 which has the basic same communication structure....but I can't seeme to get the chip to communicate using this object. Before you ask...I checked the control byte (from the MAX 1202 PDF)to make sure I'm putting in the right configuration. My confusion comes from the difference of the parameters.

Any help you guys can shed will help.

James L

pub start(control,average,ADC_addr)
· cognew(get_count(control,average,ADC_addr),@stack1)
·
·············
pub get_count(control_bit, average_sample, ADC_count_address) | temp, adresult_temp
·· repeat
····· adResult_temp := 0
····· repeat average_sample
······· delay.pause1ms(10)····························· ' wait 10 msecond···
······· outa[noparse][[/noparse]CsAdc] := 0······························· '' signal chip select
·····
······· bs2.SHIFTOUT(AoutAdc, ClkAdc,control_bit, BS2#MSBFIRST,8 ) '' put the control bit out
······· outa[noparse][[/noparse]CsAdc] := 1············································
······· outa[noparse][[/noparse]CsAdc] := 0
······· temp := bs2.SHIFTIN(AinAdc, ClkAdc, BS2#MSBPRE,12)········ '' data in
······· adResult_temp := adResult_temp + temp
······· outa[noparse][[/noparse]CsAdc] := 1
···
····· long[noparse][[/noparse]ADC_count_address] := adResult_temp / average_sample······················ ' average samples


Post Edited (James Long) : 9/17/2006 7:51:14 PM GMT

Mike Green

Parameters are positional. The values you pass are assigned to the names in the called routine in the order in which they're presented. The names are relevant only in the routine where they're defined. You can have:

pub main | r, s, t
  r := 9
  s := 7
  t := 5
  routine1(t, s, r)
  r := 2
  s := 4
  t := 6

pub routine1(a, b, c)
  cognew(routine2(c, a, b),@stackStuff)
  a := 0
  b := 1
  c := 3

pub routine2(x, y, z)
  ' here x has the value 9, y has the value 5, and z has the value 7

The fact that you have control in one routine and control_bit in another or average in one routine and average_sample in another, while confusing, doesn't matter.

James Long

Mike said...
Parameters are positional. The values you pass are assigned to the names in the called routine in the order in which they're presented. The names are relevant only in the routine where they're defined

Ok granted so the parameters only have reference to what·routine they are defined in.

So what relevance·does the·"·

pub start(control,average,ADC_addr)
· cognew(get_count(control,average,ADC_addr),@stack1

have to do with anything. I can find no declarations for these. I don't see what purpose they serve. There are no variables or constants assigned to them. Maybe I'm not asking right.

I see no need for these parameters as named. If there is a need I can't see it. I understand the parameters are there for a reason, but there seem to be no active method to act on these parameters, as they are named.

I hope that makes sense,

James L

I uploaded the file for you to be able to check and tell me I'm wrong. I assume I'm missing something....or just out in left field.

Post Edited (James Long) : 9/17/2006 10:33:20 PM GMT

Mike Green

The method code that uses the parameters is the COGNEW call. That happens to be the only thing that the start routine does. The compiler produces code that sets up for a call to get_count, but does the setup in stack1 rather than the stack that start is using. COGNEW initializes a new SPIN interpreter in a new cog and passes it the address of the current stack (stack1) and the address of the current interpretive code (get_count) and it goes from there. Essentially it does:

start:
  get value of control, push into new stack
  get value of average, push into new stack
  get value of ADC_addr, push into new stack
  set up some values for new SPIN interpreter
   (start of stack, current stack pointer, start of SPIN code)
  do COGNEW to start up SPIN interpreter and pass these values

get_count:
  there are 3 values to be found at the start of the stack
  the first is referred to as control, the second is referred to
  as average, and the third is referred to as ADC_addr

Whenever there's a subroutine (method) call in SPIN, a stack
frame is set up by the interpreter. This contains the return
address, the address of the caller's stack frame, a long for the
result value, and one long for each parameter of this call.
The result value is always initialized to zero and the parameters
are effectively initialized to the values (in order) presented in
the call. Any local variables are allocated in order in the stack
frame after the last parameter.

I hope this hasn't confused things further.
Mike

Mike Green

Without reading the datasheet for the MAX1270, I couldn't comment on the details of your routine, but I don't see any initialization of the various I/O pins. Try changing the start routine as follows:

pub start(control,average,ADC_addr)
  outa[noparse][[/noparse]CsAdc] := 1
  dira[noparse][[/noparse]CsAdc] := 1
  dira[noparse][[/noparse]AinAdc] := 0
  outa[noparse][[/noparse]AoutAdc] := 0
  dira[noparse][[/noparse]AoutAdc] := 1
  outa[noparse][[/noparse]ClkAdc] := 0
  dira[noparse][[/noparse]ClkAdc] := 1
  cognew(get_count(control,average,ADC_addr),@stack1)

James Long

Mike,

What if there are no declarations for control,average, or ADC_addr?

my problem is this is not my code.....I'm using it from the object exchange. There are no VAR or CON statements for these parameters.

I know I could pass along parameters from my top object file....but I don't see the reason to do so.

I will include the init of the I/O as yopu suggested.



JamesL

Mike Green

Look at the description of the PUB and PRI statements in the Propeller manual. I don't think the manual explicitly describes this as "declaring" the parameter names, return value name (if supplied), and local variable names, but that's what it does. All of these are always long values. It turns out that you can't use the same name for a parameter, result value, or local variable that's used for a PUB/PRI routine or a VAR variable (or DAT label). You can reuse the names in another PUB or PRI statement/declaration and a name used for a parameter, return value, or local variable is not usable outside of the routine where it's declared.
Mike