Problems starting new cogs across object boundry
I was working last night on the test structure for my Digital Storage Scope, I originally wrote it as a top level object with the DScope object declared as a dependent object and to my dismay doing the following didn't work:
cognew(DScope.Start, @stack)
So I moved the cognew into a function (StartCog)·within the DScope object, but calling DScope.StartCog from the higher level object still didn't work (I boiled the top level·down to just calling the function to make sure it was the problem, and indeed it was). Yet placing StartCog as the first function within DScope and compiling it straight works just fine. Can anyone help explain what's going wrong? DScope's dependent objects are TV_TerminalXY (a modified version of TV_Terminal which allows placement of characters at a given X,Y coordinate) and Keyboard_iso. Are there problems with those objects being used in a non-top level object? Im scratching my head here.
I have been able to embed my testing functions within DScope, but this destroys the whole premise of encapsulation. I plan on trying to distill the problem down to its minimum incarnation to figure out whats causing it, but I was hoping someone may have an answer and guidance.
BTW, Ive sucessfully tested the full speed 150nS sample period version (could see the pin 17 wiggling I was doing and captured some of the communications to the TV as well), all thats left to test is the rate specified and edge capture versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Muppet Terror Level:
·· ·![terror.php](http://www.geekandproud.net/terror/terror.php)
Post Edited (Paul Baker) : 3/31/2006 1:25:16 PM GMT
cognew(DScope.Start, @stack)
So I moved the cognew into a function (StartCog)·within the DScope object, but calling DScope.StartCog from the higher level object still didn't work (I boiled the top level·down to just calling the function to make sure it was the problem, and indeed it was). Yet placing StartCog as the first function within DScope and compiling it straight works just fine. Can anyone help explain what's going wrong? DScope's dependent objects are TV_TerminalXY (a modified version of TV_Terminal which allows placement of characters at a given X,Y coordinate) and Keyboard_iso. Are there problems with those objects being used in a non-top level object? Im scratching my head here.
I have been able to embed my testing functions within DScope, but this destroys the whole premise of encapsulation. I plan on trying to distill the problem down to its minimum incarnation to figure out whats causing it, but I was hoping someone may have an answer and guidance.
BTW, Ive sucessfully tested the full speed 150nS sample period version (could see the pin 17 wiggling I was doing and captured some of the communications to the TV as well), all thats left to test is the rate specified and edge capture versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Muppet Terror Level:
·· ·
Post Edited (Paul Baker) : 3/31/2006 1:25:16 PM GMT
Comments
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Southern Illinois University Carbondale - Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
Here's a couple teaser pics for those who aren't beta testers, this is an earlier version where I was testing the GUI, the data is a buffer of random numbers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Muppet Terror Level:
·· ·
Post Edited (Paul Baker) : 3/31/2006 1:44:16 PM GMT
... MORE INFO!...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
There are 3 different modes of capture: fast, slow, and edges. Fast captures all 32 pins at 6.66MHz for roughly 475 samples. Slow captures all 32 pins at a specified rate (Max rate is 4MHz if I remember correctly, but you can specify 1 sample every 50 seconds if you want, or anywhere in between), again it captures roughly 475 samples. You can specify a trigger condition for both slow and fast modes where you provide which pins to trigger on and what thier trigger values are (ie dont start capturing until pins 16 and 17 are 1 and pin 18 is 0). Edge mode captures a specified number of transition edges on pins you specify, and it stores the value of all 32 pins upon a detected edge and the time at which those pins were recorded.
All three capture modes can be started by the user pressing the associated key or started by a program that is undergoing testing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system!)
Post Edited (Paul Baker) : 3/31/2006 6:20:59 PM GMT
Sometimes I wish I had spent more time in my math classes...
I wonder, if I were to use a "probe" of some sort, I could use it as OScope of sorts...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system!)
...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·