Shop OBEX P1 Docs P2 Docs Learn Events
Usage of COGs — Parallax Forums

Usage of COGs

S1976S1976 Posts: 6
edited 2010-03-30 12:19 in Propeller 1
Hi all,

i have a basic question about the usage of Cogs loaded with assembly code within a SPIN program and i have difficulties to understand what´s going on. For example, i wortee some assembly code after a DAT statement and load it usual inside a PUB-Statement with Cognew. The main SPIN program itself shoud use the VGA_Text output driver, loaded here as an Object, for debugging purposes. Now i don´t understand how to tell the main program to override creating a new cog, loaded with assembly code

For example:



con
_clkmode=xtal1+pll16x
_xinfreq=5_000_000

OBJ

vg: "VGA_Text"  ' the usual VGA_Text driver
vl: "test"           'My assembly Code




pub main
  vl.start          'calls the test.start Routine which consists of creating a new Cog and loading its ASM Code, usually the cog points then to "entry   org....[noparse][[/noparse]ASM Code]"
  vg.start(16)   'should start the VGA driver
  vg.out("t")     'For testing, but it does nothing



Same problem (no VGA-output) appears also within a single program only with the VGA_Text-Driver loaded within the OBJ-Line. As soon as a cognew-command appears, the main program stops. Is it because the main-Routine always tries to reload and restart the VGA-Driver / resetting the cog or what im doing wrong? Or does the SPIN-main program wait for a statement that the cog is ready?

Many thanks!
Stefan

Comments

  • MagIO2MagIO2 Posts: 2,243
    edited 2010-03-30 05:46
    As far as I remember the propeller is stopped completely when you leave the main SPIN-code. So, in your case the vg.out will be executed, but immediately after that the whole propeller is shut down. As this is very fast and most likely is done before the VGA COG is completely loaded you won't see anything.

    Try it with an empty repeat-loop after vg.out.
  • S1976S1976 Posts: 6
    edited 2010-03-30 05:53
    Yes, that did the Trick, many thanks! Never thought about that.
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-03-30 06:20
    Each SPIN code will return if you don't have a loop which avoids that. Each SPIN interpreter you start with a COGNEW will return to a cogstop instruction which only stops the current COG. The first SPIN interpreter started by the bootloader returns to a loop which stops all COGs. So it has a special role ... whenever the main function returns, it will switch off the light ;o)

    Makes sense, as usually each program has a main-loop.

    By the way ... if you do PASM code ... you should always do a COGSTOP if your PASM code is not looping! Unlike SPIN a PASM code does not have an implicit return. PASM without a loop and without a COGSTOP can do anything ... for example variables will be executed like being instructions ... SPIN or PASM code following your PASM will be executed (in case the PASM section you started is smaller than 512 longs) ... Special function registers will be executed (for example whatever is currently found in INA ) ...
    So, you can have lot's of fun when you don't keep the COG running inside of your code ... including destroying pins because they are switched from input to output.
  • kuronekokuroneko Posts: 3,623
    edited 2010-03-30 07:05
    MagIO2 said...
    The first SPIN interpreter started by the bootloader returns to a loop which stops all COGs. So it has a special role ... whenever the main function returns, it will switch off the light ;o)
    April 1st is day after tomorrow. No seriously, if a cog exits then it exits alone (that includes #0). Everyone else keeps running quite happily. Unless I have a special batch of chips here.
    MagIO2 said...
    Special function registers will be executed (for example whatever is currently found in INA ) ...
    That's not as serious as you make it sound. Instructions are fetched from the shadow location if applicable (which is unfortunate as fetching from phsx would be quite useful). So the most dangerous thing here is usually the dira/outa content.
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-03-30 08:22
    And what happened in the given example? If the other COGs are not stopped, the VGA driver should run AND should show the "t", shouldn't it?

    INA ... ok ... same trap as usual ... shadow registers ... I wonder when I'll learn this lesson ;o)
  • kuronekokuroneko Posts: 3,623
    edited 2010-03-30 08:34
    MagIO2 said...
    And what happened in the given example? If the other COGs are not stopped, the VGA driver should run AND should show the "t", shouldn't it?
    I don't have a VGA display available so I can't test this. What I did test is the common blinking LED in a cog != #0 which continues after cog #0 goes home.

    We also don't know what his custom object does.

    If I start VGA_Text in cog #0 and just return from the main method the VGA cog stays alive (i.e. I keep getting sync pulses on the demoboard).

    Post Edited (kuroneko) : 3/30/2010 8:55:48 AM GMT
  • S1976S1976 Posts: 6
    edited 2010-03-30 12:19
    My custom object does not really do anything all in all, it only counts some cycles and writes the results into one HUB-RAM memory location, but far away from any "critical" one. This was only trying to interchange variables between the COGs. In GEAR i see that my ASM-code runs in COG2, COG0 takes the SPIN Program and COG1 the VGA-Driver. COG2 counts then, COG1 does nothing after doing some initialisation jobs, , COG0 (the Spin Program) hangs somewhere in a "FRAME_RETURN" and does nothing anymore, exctept i do the assumed "repeat".
Sign In or Register to comment.