MidiIn.Start(26, @MasterArray) 'this object file contains minimal spin just to launch assembly program #1
'wait enough time to allow this spin file to launch the assembly program then stop the MidiIn spin object.
MidiIn.stop 'this only stops the spin portion the assembly continues to run. I made sure I stopped the right cog
No, you've gone wrong there. The Spin program keeps running ( in Cog 0 ) , from start of program through the call into MidiIn.Start, and back out again.
Within MidiIn.Start() you will have launched the code which is your "MIDI input handler" in a separate Cog, most likely Cog 1, using something like 'thisCog := CogNew(...)
Calling MidiIn.Start() doesn't in itself start anything running in a different Cog but the CogNew within it does. Once you return to your PUB Main after calling MidiIn.Start() you will only have two Cogs running; one handling the Spin program ( PUB Main ) and another now running the "MIDI Input Handler".
Calling MidiIn.Start() is no different to calling a local PRI routine, it simply transfers control to another subroutine which then returnes to where it was. That routine is simply in a different object, 'objects' are not 'Cogs'.
There's nothing you need to stop, no need to call MidiIn.Stop().
deSilva, I don't doubt what I did sounds confusing but having separate files for every assembly·routine (minus the one in the top object file) for me, and me·alone, seems to work well and is easy to maintain without the risk of duplicate variables or labels.
I have something, like the code below, in every "xxxx.spin" file, with the sole purpose of launching its associated assembly routine then it gets stopped when it has completed that task.
I did not like editing code when I had more than 1 DAT section in a single .spin file.· The body of code was rather long to scroll through and obviously I wasted your time, my time and many others on this forum with my error caused in part by the compiler not complaining about a reference to a label in a different DAT section.
I am open to any suggestion which keeps the assembly sections separate and safe. You guys are light years ahead of me in programming this chip and some of my habits for from extensive VB programming rear their ugly heads every once in a while.
Again, thanks to you and all who responded to this thread. It's good to know you guys are out there.
'Sample start routine
PUB start(_midiPin, _Ptr_HubRamStartAddr): okay '_Ptr_HubRamStartAddr contains the starting address of MasterArray in hub
tmpCog :=cogid
okay := cog := cognew(@entry3, _Ptr_HubRamStartAddr) + 1
'Sample stop routine
PUB stop
'' Stop MIDI driver - frees a cog
if cog
cogstop(tmpCog~ - 1)
Post Edited (Wurlitzer) : 2/25/2008 7:14:53 PM GMT
Hippy wrote: "There's nothing you need to stop, no need to call MidiIn.Stop()."
Hmmm! I'll have to try dropping the stops and see, via Gear, what keeps running. If that is the way it works great. If you look at my response to deSilva showing the start and stop code snipits you will see what I have done.
I do like editing my various assembly routines in separate files and this method at least for now seems to work.
Hippy, thanks. That is very clear as to the proper way to handle this. It would appear that what I did was close but from your explanation I do not need the stop routines. Great!!!!!
Thanks buddy!
Comments
No, you've gone wrong there. The Spin program keeps running ( in Cog 0 ) , from start of program through the call into MidiIn.Start, and back out again.
Within MidiIn.Start() you will have launched the code which is your "MIDI input handler" in a separate Cog, most likely Cog 1, using something like 'thisCog := CogNew(...)
Calling MidiIn.Start() doesn't in itself start anything running in a different Cog but the CogNew within it does. Once you return to your PUB Main after calling MidiIn.Start() you will only have two Cogs running; one handling the Spin program ( PUB Main ) and another now running the "MIDI Input Handler".
Calling MidiIn.Start() is no different to calling a local PRI routine, it simply transfers control to another subroutine which then returnes to where it was. That routine is simply in a different object, 'objects' are not 'Cogs'.
There's nothing you need to stop, no need to call MidiIn.Stop().
Post Edited (hippy) : 2/25/2008 7:03:22 PM GMT
I have something, like the code below, in every "xxxx.spin" file, with the sole purpose of launching its associated assembly routine then it gets stopped when it has completed that task.
I did not like editing code when I had more than 1 DAT section in a single .spin file.· The body of code was rather long to scroll through and obviously I wasted your time, my time and many others on this forum with my error caused in part by the compiler not complaining about a reference to a label in a different DAT section.
I am open to any suggestion which keeps the assembly sections separate and safe. You guys are light years ahead of me in programming this chip and some of my habits for from extensive VB programming rear their ugly heads every once in a while.
Again, thanks to you and all who responded to this thread. It's good to know you guys are out there.
'Sample stop routine PUB stop '' Stop MIDI driver - frees a cog if cog cogstop(tmpCog~ - 1)Post Edited (Wurlitzer) : 2/25/2008 7:14:53 PM GMT
Hmmm! I'll have to try dropping the stops and see, via Gear, what keeps running. If that is the way it works great. If you look at my response to deSilva showing the start and stop code snipits you will see what I have done.
I do like editing my various assembly routines in separate files and this method at least for now seems to work.
Thanks Hippy!
MainProgram.spin
MidiIn.Spin
PUB Start CogNew( @MidiInPasm, ... ) DAT org 0 MidiInPasm mov ... : fit $1F0MidiOut.Spin
PUB Start CogNew( @MidiOutPasm, ... ) DAT org 0 MidiOutPasm mov ... : fit $1F0Thanks buddy!