Problems starting new cogs across object boundry

Paul Baker

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:

·· ·

Post Edited (Paul Baker) : 3/31/2006 1:25:16 PM GMT

Martin Hebel

Whenever things start acting screwy for me, I bump up the stack size and it clears up. Just a thought.
-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Southern Illinois University Carbondale - Electronic Systems Technologies

Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control

Paul Baker

Thanks for the tip Martin, I did notice I had to bump the stack up from 40 to get the cogstart to work as expected, but Im fairly certain I expanded it to 400 to be sure when trying the second time (cognew in DScope, but called from higher level object). But Ill double check tonight to be sure.

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

Kaos Kidd

This is neat!
... MORE INFO!...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Paul Baker

No prob, I was working on high speed synchronous com object (SHIFTIN, SHIFTOUT, but really fast), tried interfacing it with a color LCD screen (which has a complex startup sequence), and it didnt work. Without a logic analyzer, I couldn't determine if it was the routines on the propeller or the sequence of command that were wrong, so I decided to turn the Propeller into a logic analyzer. The pictures you see are the (mostly) finalized GUI portion of it, Im now in the process of testing the assembly routines that capture the data.

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

Kaos Kidd

Nice... Real nice...
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
·

Paul Baker

Theres a difference, Oscopes measure analog signals, this measures digital signals. But with 2-4 suitably fast parallel DACs set to auto-sample, I dont see why not, but it may take a little bit of work/circuitry to get the input block (probes/gain stage) etc to be industry standard.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system!)

Kaos Kidd

I think Dr Allen stated to the effect "with some passive circuits it could be made into a OScope"...
...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·