Fill and read LONG arrays

realolman1 · 2016-12-16 16:16

I have declared variables:

 Long  AnalogRecord[20]
 Long  ElapsedIntervals 
 Long  value

I am trying to fill the array in a loop using this line:

AnalogRecord[ElapsedIntervals]:=value

immediately after this I have all three variables sent to the Parallax Serial terminal with some characters in between so I can tell which is which.

It seems that everything is good except the value of AnalogRecord [ElapsedIntervals] , which just seems to be random multi digit numbers. "ElapsedIntervals" increments correctly and "value" varies with the analog input

Immediately before trying to fill the array with the analog inputs, I have a loop using a similar line to fill the array with zeros.

Why is the line

AnalogRecord[ElapsedIntervals]:=value

not putting "value": into the "AnalogRecord" array elements, that is indexed by "ElapsedIntervals"?
thank you

John Abshier · 2016-12-16 16:20

Not enough code to make any suggestions. If the program is too long for an inline post you can attach it.

John Abshier

ChrisGadd · 2016-12-16 16:39

Keep in mind it might also be a problem with your display routine. Try something simple like:

  value := 1000
  repeat ElapsedIntervals from 0 to 19
    AnalogRecord[ElapsedIntervals] := value
    value += 1000

...and see if it displays values from 1000 to 20000 properly.

Also, a simple way to initialize an array is longfill(@AnalogRecord,0,20).

JonnyMac · 2016-12-16 17:13

Where is value coming from? In your post it is declared as a global variable hence it will start at zero and stay there until your program acts on it. What is your program doing to act on this variable?

realolman1 · 2016-12-16 19:05

I really appreciate you all going to the trouble to try to help me.
I guess mainly I would like to know if the line

AnalogRecord[ElapsedIntervals]:=value

Is a valid syntax, and I can use another variable "ElapsedIntervals" as an index for the array "AnalogRecord"

I am sending AnalogRecord[ElapsedIntervals], ElapsedIntervals, and value to the Parallax serial terminal like this:

      sio.dec(ElapsedIntervals)
      sio.Char(61)
       
      sio.dec(AnalogRecord[ElapsedIntervals])
      sio.Char(44)
      sio.dec(value)

the only one that is wrong is AnalogRecord[ElapsedIntervals]

I thought maybe the sio.dec wasn't evaluating it correctly, so I made it equal to a long variable and tried to send that... didn't work any differently.

This whole deal is modifications of stuff I got on this website or on the tutorials.
"value" comes from a ADC object I got from here. I will attach it, although in the course of trying to figure out what is going on, it's a bit of a mess... I'm certainly not proud of it

If the values are correct, they should all be displayed on the Serial terminal I think since they are not, it seems that they are not getting assigned to the array properly

ChrisGadd · 2016-12-16 21:19

Okay, I think I see the problem. Once every five seconds you store value in the analogRecord array indexed by ElapsedIntervals, then increment ElapsedIntervals in preparation for the next record, which is the one your display routine is reading from. Try rearranging the code so:

      if seconds == secondsInterval
        elapsedIntervals++
        if elapsedIntervals == NumberRecords
          elapsedIntervals := 0
        analogRecord[elapsedIntervals] := value
        
      sio.dec(ElapsedIntervals)
      sio.Char(61)
      sio.dec(AnalogRecord[ElapsedIntervals])
      sio.Char(44)
      sio.dec(value)
      sio.Char(13)
      seconds++

realolman1 · 2016-12-17 00:28

I will try that... thank you

JonnyMac · 2016-12-17 02:08

I think you problem is associated with this line:

Coginit(2,SecondTiming,@TimeStack)

The problem is that TimeStack is defined as a single long -- what's happening, I believe, is that the code in SecondTiming is clobbering your other variables. Make TimeStack an array of 32 longs; that should be plenty for this app.

realolman1 · 2016-12-17 14:38

Well, I don't know what I'm doing for sure.

I kinda know why the stack space needs to be reserved, but mostly I don't know , and I don't have a clue how to figure out how much needs to be reserved.

I thought what I was attempting to do was reserve space for the code with the @TimeStack ...only because I thought it was required when trying to run a new cog. And I thought it would only need to be reserved for the amount of the code running in the cog. Additionally, I don't know how much the code would take

I didn't know it would be required for variables declared outside the cog.

Actually, I don't know much of anything.

Are you saying that I need to reserve enough space for the array when I want to run it in a new cog? I was hoping to make the array a lot bigger.

I was trying to modify existing stuff, and eventually I had it all hogged up trying to troubleshoot it. I think I will try to do just a small part of it, and take your advice and see how it goes.

thank you

JonnyMac · 2016-12-17 16:41

When you declare a Spin cog you have to create stack space for it; this is in the form of a long array. The size of the array depends on the number of parameters you pass, the number of local variables, and the number of calls made to other methods (and their parameters, locals, etc).

Yes, it can be black magic. For Spin cogs that don't really do much, I start with 16 longs then go from there. You can find stack space analysis tools in ObEx that will show you how much of your stack is being consumed. It's generally best to go big at first, then pare back on stack size if analysis shows that the entire stack is not being used. Just remember: if you go past the size of your stack, you may be clobbering other variables.

Also, I suggest cognew instead of coginit. If you're not careful, coginit could overwrite another active cog. Using cognew lets the Propeller use the next available cog.

realolman1 · 2016-12-18 17:42

I made a smaller program that filled an array with a number that I input through the Serial terminal and then it sent it back to me through the terminal

In experimenting with it, I discovered that you were ( as you already knew ) correct that the stack space was inadequate.

I will look into the coginit / cognew thing... the only reason I did it in the first place was that I thought it would be easier to keep track of which cogs I used

thank you for your help

JonnyMac · 2016-12-18 17:59

I will look into the coginit / cognew thing... the only reason I did it in the first place was that I thought it would be easier to keep track of which cogs I used

I don't find that to be the case.

In many of my programs I have a background cog that runs at a 1ms rate. This is used to advance a timer (called millis) and handle low-bandwidth activities (e.g., debouncing inputs, etc.) -- you'd be surprised how much work you can do in a millisecond. I start that cog like this:

  bcog := cognew(background, @bstack) + 1

The variable bcog is global so it will be zero until the cog is loaded. We add one to the result of cognew because it returns the cog number (0..7) when the cog is successfully loaded, or -1 if there are no available cogs. This means a successful cog launch will result in 1..8 (which evaluates as true [non-zero]). If there are no more cogs, -1 is promoted to zero which evaluates as false.

BTW, if you ever want to stop an auto-assigned cog, you can do it like this:

pub stop_background

  if (bcog)
    cogstop(bcog - 1)
    bcog := 0

(FTR, I don't use the post ~ or ~~ operators in my programs; you'll find other stop() methods that do).

Fill and read LONG arrays

Comments