noob needs help with cogs objects and variables - RESOLVED
CrazyJennie
Posts: 5
Hi all. I'm kinda new to spin and the prop.
what i am trying to do is scan some light sensors really fast, play midi notes, while at the same time keeping an eye on the ps2 keyboard, and occasionally sending stuff to an LCD.
It seems that its time to learn to use more than one cog at a time [noparse]:)[/noparse] I'm thinking the 'right' way to do this is to have 1 cog
poll the CdS light sensors, 1 cog handle the midi and have those cogs update some variables that the rest of my program can access when it wants.
but separate cogs seem to have trouble using included objects, and separate objects seem to have trouble using the main variables.
my questions are, is that the right way to do it, and, how do i do it?
I can't find any documentation that makes this clear.
suggested reading or any help would be greatly appreciated
Post Edited (CrazyJennie) : 2/21/2010 10:25:20 AM GMT
what i am trying to do is scan some light sensors really fast, play midi notes, while at the same time keeping an eye on the ps2 keyboard, and occasionally sending stuff to an LCD.
It seems that its time to learn to use more than one cog at a time [noparse]:)[/noparse] I'm thinking the 'right' way to do this is to have 1 cog
poll the CdS light sensors, 1 cog handle the midi and have those cogs update some variables that the rest of my program can access when it wants.
but separate cogs seem to have trouble using included objects, and separate objects seem to have trouble using the main variables.
my questions are, is that the right way to do it, and, how do i do it?
I can't find any documentation that makes this clear.
suggested reading or any help would be greatly appreciated
Post Edited (CrazyJennie) : 2/21/2010 10:25:20 AM GMT
Comments
A tip. When you ask about some code, post the whole code using the archive function in PropTool. If you show a snippet, use the code icon in the "Post Reply" section (not the Quick Reply) so that your formatting is maintained.
Now to your question. Yes, use a different cog for each of the important routines. There is already a PS2 Keyboard object, a serial object, a number of displays including LCDs, and a host of others. Finding them is your biggest challenge.
If you run through the examples in the Prop Manual you will see it gets to flashing leds with different cogs fairly quickly.
What hardware do you have? Then maybe we can suggest some example code for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
So the object actually exists in two cogs at once. What happens in the case of keyboard is that when it is started an address to some hub ram is passed to it "@par_keys" this means that the code running in the new cog knows where to put the data it creates. The key function can then just look at this data stored in the hub.
So you often start a new cog passing a pointer to some hub ram as you do, that code can then modify the hub ram and helper functions that are in the original cog can be used to access this data easily.
I hope that is some help.
Graham
@Cluso99
Thank you, i didn't even know about the archive function. i've attached the code i've got so far.
I'm using a protoboard , and i have actually managed with the help of objects from the site to get the whole thing up and running. its just a bit too slow because, i need to learn to write software hehe.
@Graham
Thanks so much your reply was very informative. I had suspected it had something to do with pointers, but i can't find documentation on the right way to do it.
@everyone
let me ask two very specific questions.
1) is it possible to have a loop constantly run in a cog that repeatedly updates a variable and wont block the main program. for example i would like to constantly use the ping sensor, and store values in a variable that i can access from the main app.
2) how do i do that, exactly. How to i write that object, launch it, and how do i tell it to store the info in a specific variable.
or if someone could have a look at my code and make a suggestion, that too would be greatly helpful. thanks again for your time and input.
p.s. here's a youtube vid of the thing, if it helps explain what i'm trying to do
www.youtube.com/watch?v=jXdIYHTrktg
Post Edited (CrazyJennie) : 2/20/2010 12:45:59 PM GMT
Another way is to put it into a cyclic buffer, the same way as the FullDuplexSerial works.
So from you video and discussion (BTW the video looks great) your ping sensor will likely be a few longs of info. However, each sensor would only be 1 long, so that will not matter. Just write a value each time you get one and the other can read at any time because the value will always be valid as the last written.
So what you have to do is declare a block of long variables and you pass a pointer of this to the respective cog(s) when you start them. One cog will write to them each time it gets a new sample, and the other cog will read the value when it has time and process it accordingly. Does that make sense?
OK, I have had a quick look at your code. Spin is way slower than pasm, but that is probably not the issue here.
How often do you update the LCD? There are delays in here and you could get it into another cog and just pass the data you want output to a buffer and ignore how it gets onto the LCD. Just like FullDuplexSerial. There are LCD drivers in the OBEX that may show you how to do this, or you may find one that already works with your LCD.
In the strum code, the update_keyboard would most likely·be faster in a case statement.
However, you are right in that you want to get the time sensitive code into a cog of it's own.
So, can you split your code into the·string input in one cog and when it processes it, just update the variables.
You could do the same for the output code that drives the midi.
Do you know how to start another cog with spin code? Make the top routine a PUB and it's private routines PRI. Put a comment horizontal line between the top of this code and the bottom of it so it is easy to tell which parts are together. Then do a cognew (to start this process in a new cog) giving this a start address and a buffer address. If you do not split the program into another file, you don't have to pass it the address of·the global variables.
I hope I haven't confused you with my ramblings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I'm still a little confused about pointers, cogs and objects.
what would the cognew statement for that look like? would it be something like
In the cog its launching, how would i access the fred variable, and the ones following it?
In that cog, how do I access the ping object?
Should i make this bit of code an object itself in another file or just a pub routine in the main one?
A quick example would be greatly appreciated. I've tried a number times and all i can manage to do is get it to lock up. Maybe its because i'm using spin and not pasm?
I'm sorry that I'm so slow at picking this up, i've been using computers for far too long and this whole multi-processor thing is hurting my brain lol
Theres a good discussion of cogs and objects in the Propeller Education Kit. Look at the "sticky thread" for the PEK Labs.
Here is how you would make poll_cells run in a seperate cog...
This may not be what you want, but it demonstrates how to do it.
var long stack_poll_cells[noparse][[/noparse]20] 'stack space long cog PUB StrumBoard SetupVariables StartHardware cog := cognew(poll_cells,@stack_poll_cells) +1 'start poll_cells in a seperate cog 'Main Loop repeat 'the bad part, i need to put these in seperate cogs i think ''' poll_cells '<=== running in another cog update_strings update_keyboard pub poll_cells 'check state of CdS cells repeat '<=== make it a continuous loop if(ina[noparse][[/noparse]CdS_1]==1) 'if CdS_1 is high CdS_1_wait := 1 'go into a waiting state if(ina[noparse][[/noparse]CdS_2]==1) CdS_2_wait := 1 'this way notes only get triggered if(ina[noparse][[/noparse]CdS_3]==1) 'when the pins go from high to low CdS_3_wait := 1 'instead of repeating while held low if(ina[noparse][[/noparse]CdS_4]==1) CdS_4_wait := 1 if(ina[noparse][[/noparse]CdS_5]==1) CdS_5_wait := 1 if(ina[noparse][[/noparse]CdS_6]==1) CdS_6_wait := 1 if((ina[noparse][[/noparse]CdS_1]==0) & (CdS_1_wait == 1)) 'when it goes high, while waiting string1_timer := 10000 'start the note timer CdS_1_wait := 0 'and reset the wait state if((ina[noparse][[/noparse]CdS_2]==0) & (CdS_2_wait == 1)) string2_timer := 10000 CdS_2_wait := 0 if((ina[noparse][[/noparse]CdS_3]==0) & (CdS_3_wait == 1)) string3_timer := 10000 CdS_3_wait := 0 if((ina[noparse][[/noparse]CdS_4]==0) & (CdS_4_wait == 1)) string4_timer := 10000 CdS_4_wait := 0 if((ina[noparse][[/noparse]CdS_5]==0) & (CdS_5_wait == 1)) string5_timer := 10000 CdS_5_wait := 0 if((ina[noparse][[/noparse]CdS_6]==0) & (CdS_6_wait == 1)) string6_timer := 10000 CdS_6_wait := 0BTW: The Prop Manual is very helpful. You can access it from the PropTool Help menu. You need v1.2.6 r 1.2.7 for the latest manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 2/21/2010 7:27:31 AM GMT
If you have any questions on how the programming works, let me know.
I am about to release v2.0 which has many enhancements.
You could actually use this platform to generate your sounds inside your instrument, no midi interface needed.
You could also combine the two. I am in the process of doing this with my device.
I like your use of lasers as sensors, mind if I steal that from you?
In exchange, I'll tell ya, that you can use simple LEDS as sensors for your lasers, much cheaper than your sensors,
and they work very well.
My device uses leds as sensors.
Welcome to the propeller, enjoy your stay.
[noparse]:)[/noparse]
http://forums.parallax.com/showthread.php?p=831833
Thanks so much to all of the replies, and for the patience. After multiple manual reads, faq checking and example code tinkering I was still stuck. But thanks to you guys I think i finally have it figured out.
my 'ping scan' cog keeps dying but i'm sure i'll figure that out.
Clock Loop, that is wild! retro, modern, and it sounds great. I've thought about adding built in sounds, but that's something i can
add later if i have the cogs and ram for it.
I also considered LED's as light sensors, along with a lot of other thigns. I think next i'm going to try fiber optics, mounted to some kind of tension sensor. What I'd really like is a hex guitar pickup.. but those are like 200 bucks. I want the 'guitar action' to be as real as possible, at an affordable price.
Your more than welcome to use lasers, just stay away from the walgreens ones or any other laser pointer for that matter if you can help it. The ones i got had lenses mounted on springs, mounted on soft plastic inside an un-removable housing. soldering made the plastic melt, which threw off the focus permanently.
I saw online where u can buy 2 modules with built in power regulators for $5 though, so all is not lost.
Your doing great on your project and although you have a few things to work out it shouldn't take long . As you found out their's plenty of talented people willing to offer a few tips.
cgi.ebay.com/ROLAND-GK-2-MIDI-GUITAR-PICKUP_W0QQitemZ150416446619QQcmdZViewItemQQptZGuitar_Accessories?hash=item230584d49b
Good luck and have fun!
I have taken those crappy laser pointers apart and they are not easy, but once you can get at the diode, you don't need the lens.
Of coarse depending on the type of laser pointer, they may glue it all, something a dremel can solve.
Thanks for the tip, but I need a source for multiple new parts, i want to build and sell a few of these eventually.
@Clock Loop
if you take the lenses out, they just become LEDs right? or am i missing something? All of the one's i've taken apart are just a little lights that happen to emit a very thin band of light, with some special optics to focus them
The one I had did have some light scattered around a very bright point, with a thin band of slightly visible light.
But were def lasers, they had metal housing around the laser. They also had focusing lenses, (which I kept to remove the slight line banding)
I suppose soon they will just start using bright leds with optics. (leds are up and coming, replacing our christmas lights is just the start of this LEDOLUTION!)
The lenses in a laser pointer (unless used to create a line) collimate the beam, what comes out of the diode itself is a very wide angled beam, this is then collimated into a parallel beam that is useful for pointing at things.
A lot of laser pointers have quite nice little laser modules in them but it is not expensive to buy the modules by themselves.
Graham