COGNEW question

lardom

I need help understanding the cognew command.·Does cognew work for an entire object as well as for a method? My project will include a stepper, an LCD and a keypad. It could optionally have a hall effect sensor and a servo. If an object can be assigned to a separate cog does anyone have an example?

MagIO2

COGNEW does not create new objects. That's maybe what you could think when comeing from Java or C++ with it's new instruction. COGNEW used with function-names is only loading a SPIN interpreter into a new (free) COG and starts program execution with the given function.

Objects in SPIN are static. Each Object listed in the OBJ-section is created at compile-time and can be used in all SPIN COGs that have been started in the same .SPIN file.

For example:
Let's say you have one LCD object. You have the main COG and another one has been started. You can use that one LCD-Object in both COGs, but you have to make sure that you don't use it at the same time from both COGs. That will cause problems (using the same variables/using the same display)! And that's what the lock-instructions are good for. So, before using the LCD both programs have to try to get a lock. If this is successfull (which it will only be for one) it can use the LCD and free the lock when it's done. If getting a lock is unsuccessfull you can wait or continue with something else and try it again later.

Another scenario is, that you have an object that handles ... say a temperature sensor. Now you attached 2 sensors on different pins and want to monitor both from different SPIN-code running in different COGs. Then you might need 2 objects in the OBJ section. For example temp1 and temp2. Or you can do it as an array temp. The different code sections then have to use the right object. This is not a problem, because each object has it's own var-section.

Peter Jakacki

Larry, there is no problem if you assign a cog to handle the stepper and pass commands to it rather than sometimes trying to do it yourself from the main startup cog as you had been doing. But if you use cognew it is far better that you leave the cog running rather than letting it shutdown and then trying to start it up each time. Assign another cog to the keypad and even the same one for the lcd would be ok as there aren't any real timing issues with these. Run your application from the startup cog and launch these two other cogs to do their job.

Things such as temperature sensors surely don't need cogs as you just read them when you are ready. It is possible though to have say the keypad cog act as a background task and just poll these sensors and update a variable in hub memory that can be accessed globally. Does this make sense?

But maybe you need to be more specific about your application rather than trying to be specific about how you think it should be implemented. You seem to be specifying it in terms of cogs and objects but you should have it clear in your own mind first what you are trying to achieve from a non-technical point of view, what it needs in terms of peripherals, why, and what it is going to do with it, independently of any particular processor. Of course the Propeller will be able to handle it all easily anyway. Partition the process from the processor and then you can blend them together.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

lardom

Peter, better yet you can see the Pbasic version of my machine on Youtube. My username is "3deeguy" and the video is called "prototype done".
MagIO2, I started learning Pbasic, I think, late in '08'. I designed my first 'camera slider' early that year in which I used a modified servo, a 555 chip, a door hinge and ball-bearing drawer pulls. (It worked). I was buying supplies from Radioshack for that project when I saw "What's a Microcontroller" and bought it thinking I would learn about it when I had time. The kit sat for several months unopened.
The thrill of previous accomplishments wears off after awhile. New challenges get rid of the blahs. I am glad to have found a community of people that share the passion I have for this stuff. I want to extend a digital handshake to those forum members who are so willing to share their knowledge. At some point I will be able to do the same. Thanks.

mpark

lardom, I watched your video. Your device looks neat but what is it for?

lardom

mpark, I take 3D photos. I shoot in "burst mode".·A motorized track will give you a ruler straight sequence of pictures. I built the digital model so my wife and daughters could do what I did. A spin version will allow me to build it for different cameras. I haven't taken any pictures recently because· Spin is, at the moment, a bigger challenge.

· The Prop opens up a zillion possibilities to create some of the things I can imagine. It's tough to communicate my excitement but I think a lot of forum members can identify with that.

MagIO2

Wouldn't it be easier to mount two cameras side by side and have some electronics to shoot two photos simultaneously? Then you could even do action photos. Wanna see your solution making photos of your daughter playing or running or jumping.

Can you tell why the track needs to be so wide? Isn't it enough to shoot the photos with a distance that the eyes are apart from each other?

lardom

MagIO2 said...
Wouldn't it be easier to mount two cameras side by side and have some electronics to shoot two photos simultaneously? Then you could even do action photos. Wanna see your solution making photos of your daughter playing or running or jumping.

Can you tell why the track needs to be so wide? Isn't it enough to shoot the photos with a distance that the eyes are apart from each other?

I do lenticular 3D and I typically take 12 or 24 pictures. I process those pictures on my computer and laminate the composite photo to a lenticular lens. You are thinking of anaglyph 3D which requires 3D glasses. I use 3D glasses only to proof my work.

······································· I forgot to add that If you zoom in you need to move the camera more.

Post Edited (lardom) : 3/3/2010 7:21:29 PM GMT

Peter Jakacki

That looks great Larry but you could have posted the url www.youtube.com/watch?v=BY0eCi7RRXA

So the device looks simple enough and you have implemented it well, how is the new one different? Do you have a block diagram or a schematic or even a rough sketch?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

lardom

Peter Jakacki said...
That looks great Larry but you could have posted the url www.youtube.com/watch?v=BY0eCi7RRXA

So the device looks simple enough and you have implemented it well, how is the new one different? Do you have a block diagram or a schematic or even a rough sketch?

I couldn't figure out how to post the url. I hope you don't mind telling me how to do it.

There are several reasons I want to build a spin version.
1) A lot less expensive. I had to buy a Memkey for the keypad and a LittleStepU for the stepper.
2)·My camera shoots 3 pics·or 6.2 pics per sec in burst mode. Other cameras shoot 5...10...etc. I'm thinking of using datalogging to configure it for different cameras.
3)Much smaller footprint. I had to use two·radioshack project boxes and I could eliminate one of them.
4)·I have the option of adding a few bells and whistles without having to be concerned with memory.
5) Less weight. There are better machines than mine but I wanted a portable machine that I could take among the trees.
· I don't have a block diagram. I will tweak the program many times·until I'm satisfied·that what I've done makes sense. After I'm done with this machine I expect to move on to something different. I may start tinkering with a robot arm. I really do like this stuff.·

Peter Jakacki

Larry, the block diagram is just for the hardware mainly so we know what we are dealing with and worrying about the how later. Sometimes you can simply document this in the header of your Spin file even using the graphics characters to draw diagrams.

If you ever want to include a URL that people can just click then just click the URL button above your edit box and paste the link and then click the URL* box again. Usually I just type this in manually as the formatting commands are encapsulated with [noparse][[/noparse] square brackets ]. That's also why code listings get messed up when it's posted because if you have any square brackets in it then it will be interpreted as mCode (look at the mCode Help link above the text when you edit). The easy way around this is simply to pad the left brackets in your listing with an extra space after it.

So your hardware devices includes:

• Stepper
• LCD
• Keypad
• Hall effect sensor option
• Servo op

If you are not sure how to partition the cogs and functions then just devote a cog to the stepper and one for the keypad maybe. The LCD can just be written to as required. Have the stepper object sit in a loop waiting for commands etc. Maybe you can even have a stepper command buffer that you can write to from the application a bit like a serial buffer if that would be advantageous. But don't complicate it first up, just get it FUNctional first.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

lardom

Peter Jakacki said...
Larry, the block diagram is just for the hardware mainly so we know what we are dealing with and worrying about the how later. Sometimes you can simply document this in the header of your Spin file even using the graphics characters to draw diagrams.

If you ever want to include a URL that people can just click then just click the URL button above your edit box and paste the link and then click the URL* box again. Usually I just type this in manually as the formatting commands are encapsulated with [noparse][[/noparse] square brackets ]. That's also why code listings get messed up when it's posted because if you have any square brackets in it then it will be interpreted as mCode (look at the mCode Help link above the text when you edit). The easy way around this is simply to pad the left brackets in your listing with an extra space after it.

So your hardware devices includes:

• Stepper
• LCD
• Keypad
• Hall effect sensor option
• Servo op

If you are not sure how to partition the cogs and functions then just devote a cog to the stepper and one for the keypad maybe. The LCD can just be written to as required. Have the stepper object sit in a loop waiting for commands etc. Maybe you can even have a stepper command buffer that you can write to from the application a bit like a serial buffer if that would be advantageous. But don't complicate it first up, just get it FUNctional first.

· I see. The hall effect sensor would be used to establish "home" position. I might accomplish the same thing by calculating stepper movement. I like less hardware. The servo would be used to maintain the camera's aim toward the main subject by rotating the tripod head...but wobble is an issue and I would need a custom designed tripod head. I corrected·my wobble problem by ramping and by buying a more expensive tripod head that had hinges on both sides instead of just one. Because I like a simple, lightweight, portable design I wanted an ethernet jumper wire·that I could replace· easily. If I could accomplish datalogging without adding an SD card·reader so much the better but it appears·that extra hardware·might be necessary.
··A previous problem that you helped me with when I referred to 'line 112 mangling line 114' was corrected by removing the COGNEW command. You helped me·see·where I screwed up. I am embarrassed to be so dense but I've had problems understanding the 'start method'.I will study the posts from you, MagIO2 and·reread the·PE Labs book. I will not post again until I have a corrected start method. Thanks.