Need help reading file from VMusic2

Duane Degn · 2011-07-06 18:31

Wouldn't you know it, the Propeller Manual v1.2 explains it pretty well. Near the bottom of page 80:

Instead of launching SomeObject.Method into another cog, the Propeller instead executes SomeObject.Method within the current cog and if that method returns a value, the Propeller will take that value and use it as the address of code to launch with the COGNEW command. This will not result in the code writer's intend effect.

Wow, I did not know that.

I have a hard time thinking of when using cognew that way would be useful.

Duane

Edit: Thanks kuroneko!

Vadoo · 2011-07-06 19:44

I'm still doing something wrong. All I did was take one working object, split it into two objects, and tried to bounce the address of the important data around.

VAR
  Long Stack[32]

PUB Start(FillBuff,Finished, SeqEnd, Buff)

      

cognew(Shift_Out(FillBuff,Finished, SeqEnd, Buff), @stack)




PUB Shift_Out(FillBuffer, Done, SeqRemainder, BuffData) | data


DIRA[10]:=%1     'setup for pins                  
DIRA[12]:=%1                                             
DIRA[11]:=%1                                            
OUTA[10]:=0
OUTA[12]:=0                                             
OUTA[11]:=0
dira[20]~~

    


byte[FillBuffer]:= -1
       

repeat
  data:= buffdata
 repeat 2
 
   
  if Done== -1
    repeat byte[SeqRemainder]
    
    repeat 16
       !outa[20]        'heartbeat led
                         repeat 2               'shifts all 32 bits before pausing

                           
       
                           repeat 16            'shifts in 16 bits and latches   
                             if byte[data++] == $ff
                                OUTA[11]:=1            'data high                              
                                OUTA[10]:=1            'clk high
                                OUTA[10]:=0            'clk low
                                OUTA[11]:=0            'data low
                             else
                                OUTA[11]:=0            'data low                              
                                OUTA[10]:=1            'clk high
                                OUTA[10]:=0            'clk low
                             
                                
         
                          OUTA[12]:=1            'latches in data  
                         waitcnt(cnt + clkfreq/10)
                 
      
    
       
    if byte[Done]== -1
      quit
  byte[FillBuffer]:= -1

My heartbeat led comes on but it doesn't do anything after that. So it seems to be the way I'm trying to use the data pointer?

Duane Degn · 2011-07-06 20:21

Vadoo,

I'm not seeing anything obvious.

It would probably help if you post the original object plus the two splinter objects.

I wont promise to look at them but someone probably will (I probably will, for some reason* I'm spending a lot of time on the forum today).

Use the "Archive" feature to combine all the objects in a project.

Duane

*I'm pretty sure the reason is my wife is out of town. I'm trying to make the time pass faster.

Vadoo · 2011-07-06 20:30

This is the working program and all of its bits and pieces.

Sorry not familiar with the archive feature. Please explain and I will use it from now on.

Vadoo · 2011-07-06 20:31

And this is the attempted modified version.

Vadoo · 2011-07-06 20:35

Found it! I think I did it correctly

Duane Degn · 2011-07-06 20:57

I'm not seeing anything yet.

Try increasing the stack to 100. You've got a lot going on in that cog. 32 might not be enough.

Duane

Vadoo · 2011-07-06 21:02

Heartbeat light comes on and stays on still...

Vadoo · 2011-07-06 21:09

I deleted a bunch of stuff in my crazy mess of a loop and I seem to have a working heartbeat light. I'm playing with that a bit more to see if I can tell what kind of data might be moving around during that. No blinky blinky yet on the shift registers...

Duane Degn · 2011-07-06 21:12

You've got a crazy way of indenting code.

I can see it could be helpful if you're used to it but it started to make my head swim.

Duane

Vadoo · 2011-07-06 21:17

Ya I'm jumping in to a bit of a project that was way over my head when I started. But I learn best that way

The unfortunate side effect is my somewhat messy looking code. So any criticism is welcome if it will help me standardize a little bit my code writing.

Vadoo · 2011-07-06 21:45

As a very simple test I tried this:

dira[20]~~

outa[20]~~
waitcnt(cnt + clkfreq)
outa[20]~
waitcnt(cnt + clkfreq)
       

 
 

    repeat 512
      data:= byte[buffdata++]
       if data == $ff
                              outa[20]~~
                              quit

It should have 512 bytes to read. At the end of that first 512 there are a couple $FF values. So I would think this code would make my LED turn on and stay on. But I get nothing..
This is replacing everything that was to be started in the new cog.

I do get the LED on for a second and then off as the first part of the code is set up to do.

Duane Degn · 2011-07-06 22:07

What are the other cogs doing with that pins.

The Prop has some rules that I'm still not straight about with using a pin in more than one cog.

I personally try to limit the use of a pin to only one cog. It make life easier.

Duane

Vadoo · 2011-07-06 22:11

I've cut out everything and simple stored $FF to the store point in the main object. (buffer:= $FF)

Then in the second object, new cog, I set up to turn on an led on pin 20 if the data pointer equals $FF. (if byte(databuffer) == $FF outa[20]~~)
Still not working..

Duane Degn · 2011-07-06 22:27

I try to avoid statement like this:

byte[FillBuffer]:= -1

-1 equals $FFFFFFFF which doesn't fit in a byte.

so byte[FillBuffer] will equal $FF which might work for what you want to do but I avoid such code because $FF does not equal -1

Duane

Vadoo · 2011-07-07 18:08

I've tried writing many very simple programs to write a value to a store point, transfer it to another object, transfer that to a new cog, and use that data for something as simple as turning on an output on the prop. And I just can't get it to work.

If someone can show me a very basic way of doing something like that properly, maybe I can make sense of this whole mess. I'm going back to some of the educational material to see if I can find something there that will clear it up for me.

Duane Degn · 2011-07-07 21:39

Here's a program that sends the address of an array to a child object.

The child object launches a cog to turn on LEDs based on the values in the array.

I used the LEDs on the QuickStart board but you can use any set of eight or fewer consecutive pins.

Just change these constants:

_FirstLedPin = 16
  _LastLedPin = 23

It ended up not being as simple as I had initially intended it to be.

Cog #1 turns the LEDs on based on the bit patterns in the array.

Cog #0 keeps change these bit patterns.

The array starts with only one high bit. This bit is rotated so a different LED is turned on with each element of the array.

Cog #0 keeps increasing the number of high bits until all eight LEDs are turned on.

Cog #1 is also watching for an array value of $FF. When it finds this value it flashes the LEDs.

I'll be glad to add comments when I have more time.

I can also simplify it tomorrow if it would help.

Duane

Vadoo · 2011-07-08 18:29

Thanks this works great! I'm going to start tearing it apart and finding out what makes it tick, and see what I can learn from it that will make my project work! It seems to be fairly easy work through, but If I get stuck sorting through it I'll yell for help!

Duane Degn · 2011-07-08 18:35

I'll be among those watching for your yell.

Duane

Vadoo · 2011-07-09 12:06

Tip of the day:
Surge protectors work much better when any other potential surge entry points are equally protected. Such as coax.

Lost three tv's, one microwave, a digital thermostat (which turned itself on high though it was off, and heated my sons room to 103 degrees), one outside pole light (where the lightning hit), one outside receptacle, one Dish Network box and a hallway light...
Fortunately the house is standing, and non of us were home when it happened.
So no tv for a bit, more time to work on my Prop!

Vadoo · 2011-07-09 12:09

Duane,
Let me know what you think about this. I made a lot simpler version of what you sent me with the basic idea of being able to send data addresses. I think I can take this and upscale it to my project now

I'll be working on this for a bit today (while I wait for the Dish Network guy to come give me back my tv!)

I suppose the most important part is, I GET IT NOW! (I think)...

Thanks!

Duane Degn · 2011-07-09 12:28

Yes, that is much simpler.

I hadn't intended to make my example so complicated but I started thinking about how to make it obvious that cog #0 changed the array that cog #1 was reading and displaying on the LEDs. I got kind of carried away with making the LEDs change patterns which complicated the example.

You realize that cog #0 in your example stops after starting the child object right?

I'm very glad you're "getting it". This is one of the things that makes the Prop so powerful.

Duane

Vadoo · 2011-07-09 12:33

Yes I realize it stops, and it actually was very helpful seeing how yours interacted between cogs as far as exchanging new data. I'll need that kind of interaction in my next step of the project. I'm starting to fight with that a little right now.

Vadoo · 2011-07-09 14:02

I have some success!

My data pointers work from the main to the second object. But I cant get it to work in reverse.
I'm trying to tell the main when the entire buffer has been read and it needs to refill it. I have tried:

byte[BufferEmpty]:= 0 (in the second object)

Then when Main see this it will run the buffer fill again.

repeat
   !outa[23]
   waitcnt(cnt + clkfreq)
  if buffempty == 0
     quit

But its not working. I'm sure I must be passing the 0 back incorrectly.

Duane Degn · 2011-07-09 14:58

We'd need to see more of your code.

Do you need "byte[@BufferEmpty] := 0"?

If you new code is a short as the last code you attached, the problem shouldn't be hard to find but we need to see it all.

Duane Degn · 2011-07-09 15:01

Or how about

  if byte[buffempty] == 0

?

Vadoo · 2011-07-09 21:09

This one is not all that short. I took a few mins to notate and clean it up, but its still a little messy. I put a bunch of '''''''' where the problems start...

kuroneko · 2011-07-09 21:22

Vadoo wrote: »

This one is not all that short. I took a few mins to notate and clean it up, but its still a little messy. I put a bunch of '''''''' where the problems start...

The start method of your shift object takes four addresses. Why do you place them in byte variables? You should at least use words.

Vadoo · 2011-07-09 21:30

kuroneko wrote: »

The start method of your shift object takes four addresses. Why do you place them in byte variables? You should at least use words.

I didn't think I would be using any more then a byte in each variable. I'll try making the change and see what that does.

Now that I think about it the addresses are more then a byte aren't they..

kuroneko · 2011-07-09 21:33

Vadoo wrote: »

Now that I think about it the addresses are more then a byte aren't they..

Most of the time they are. Just press F8 and check where the yellow (VAR) area starts. That's your expected address range/area.

Need help reading file from VMusic2

Comments