CogNew to a second Prop?

TJHJ

Hey all,
I was wondering if anyone has done anything to init a new cog on a second propeller chip, out of the main program on the first chip?

If someone has done this already then no point in repeating what someone has already done. If not I have a feeling that this is a such a simple idea and really hard to execute in reality. I was thinking that seeing what has been done with Prop dos (Thanks!) and its ability to read multiple E-proms and to be able to load new cogs from programs/code, to a second propeller, or 3rd, could be very use full.
I have found that with out interrupts running multiple time sensitive systems, can suck up a lot of cogs very quickly, and the calculations associated that, make me want to have more cogs. Its not the Ram/Rom that is so much the limit IMO, but having to dedicate a cog to catch a time sensitive data, so to be able to add a prop, to watch and catch data would be very use full.

Thanks again all, If this has not been done, I can take a shot at it, and see where I can get.

TJ

Edit* I have seen that prop 2 has plans for more cogs.. but when prop 2 is IDK?

Jimmy W.

yes, you can launch a new cog on another prop,*sort of*, Chip has some code on obex for loading a bin file from either a file that was included in the original program, or from the 32k-64k area of eeprom, and there is code I posted a while ago to load a file from sd and send it to another prop
Considerations:
reexamine your needs.
Are you using multiple cogs for serial> if so check out Tim Moores excellent 4 serial port driver, we should all praise him for that.

Understand that you are going to have to dedicate at least 2 cogs on the second prop and at least 1 on the first prop ( depending on your app) just to stay in communication with each other

Once the program is loaded on the second prop, the first order of business should be a good handshake between the 2, after that I would write it for ease of use, make the second props main cog wait for commands from the first prop and execute them just as if you would normally (this is actually the easy part)

I originally had 4 props specified for an ongoing project, and I wrote 90% of this already, before getting it shoehorned into 1 prop, you probably can get away with 1 prop using a spare pin as an interrupt


Oh, the other way to write it would be to only write 1 program but have it check the state of a pin to see if it is the master or slave, that way you just upload the same program, or just give the second prop an eeprom programmed to the same as the first


Edit: oops looks like the first time I clicked new post instead of reply !

TJHJ

Jimmy W. said...


ou probably can get away with 1 prop using a spare pin as an interrupt

Hang on a sec.. I thought we didn't have an interrupt commands? or has someone slipped in a software one that I have somehow completely missed?

Thanks TJ

KenBash

Hi Tjhj,

I have a board I built with 3 propeller chips on it ( I couldn't resist calling it the "Tri-motor" ) I put together a simple communication function that used two I/O lines, one as a master clock and the other as time-sliced bidirectional data for each prop. ( Honestly, the Full-duplex function is probably just as good, but mine didn't require quite as much code to implement. ) I didn't do anything as complex as starting additional cogs with it, just passing flags and data between three propellers, but I can see how you could easily have a cog on each chip doing nothing but monitoring data and responsible for starting other process on the same chip. This would give you a board with 21 cogs available for ... whatever.

I look forward to the new chip also... but have the feeling we'd better plan to live with the Prop 1 for a few more months. ( besides, it's QUITE a chip all by it's own-self)

Ken B.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "

··············································· ( R.A.H. )
····································

Mike Green

TJHJ,
There are no interrupt commands. There are no hardware or built-in software interrupts. On the other hand, "interrupts" is just a concept and you can implement the idea. For example, the Large Memory Model interpreter can be rewritten to include "interrupts". Adding this would slow it down, but might be worth it for some applications. The Spin interpreter can now be modified to include some kind of interrupt, particularly if you're willing to devote a 2nd cog for the expansion. You could probably throw in floating point if you wanted. None of this would be trivial, but technically it's not difficult.

Jimmy W.

Mike Green is correct of course, there is nothing built-in, but depending on how you build your program it is quite easy to do, I broke my program into the littlest bits I could, then used a State variable to tell me what step to take next, first checking to see if an interrupt happened depending on your program this could be quite simple or quite complex to implement

TJHJ

Yeah, I thought I had been missing a whole bunch there for a bit. Thanks for the help all.
TJ