Cognew - I really should know this by now...

Vega256 · 2011-06-11 20:07

con

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

var

  byte data
  long stack

pub main

  data := 10
  cognew (startRenderCog, @stack)

pub startRenderCog

  dira [24..27] := %1111

  repeat
    outa [24..27] := data

I have four LEDs connected to I/O pins 24-27. When the code is run, no LEDs are lit (I am aware that 10 would be 1010). Is there something special I should know about cognew? I haven't utilized parallel processing extensively.

kuroneko · 2011-06-11 20:10

con

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

var

  byte data
  long stack[COLOR="red"][32][/COLOR]

pub main

  data := 10
  cognew (startRenderCog, @stack)

pub startRenderCog

  dira [24..27] := %1111

  repeat
    outa [24..27] := data

One long isn't enough. As bytes get re-ordered after longs data is most likely reset to 0. That said - just checked - even forcing data to be before stack doesn't help which suggests that the exit code path for cog 0 or the global stack gets scrambled in a way which affects your newly started cog.

Vega256 · 2011-06-13 13:29

kuroneko wrote: »
con

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

var

  byte data
  long stack[COLOR="red"][32][/COLOR]

pub main

  data := 10
  cognew (startRenderCog, @stack)

pub startRenderCog

  dira [24..27] := %1111

  repeat
    outa [24..27] := data
One long isn't enough. As bytes get re-ordered after longs data is most likely reset to 0. That said - just checked - even forcing data to be before stack doesn't help which suggests that the exit code path for cog 0 or the global stack gets scrambled in a way which affects your newly started cog.

Is there anywhere that I may declare variables and not have them scrambled?

Dave Hein · 2011-06-13 14:31

The stack for startRendCog needs to have a few longs on it even though it doesn't have any stack variables. At the very least the stack must contain 3 longs for a stack frame and the RESULT value. If you do any operations at all you will need stack space to hold temporary values. I usually use a stack of at least 20 longs, or more if I'm not bounded by memory.

If you declare your varaibles in a DAT section they will not be re-ordered.

Vega256 · 2011-06-13 14:36

I just found the issue. I was exporting the code in the wrong format. I should have used .eeprom instead of .bin. The strange thing is that for all this time, I have been using .bin and it hasn't acted strangely until recently.

kuroneko · 2011-06-13 17:55

Vega256 wrote: »

I just found the issue. I was exporting the code in the wrong format. I should have used .eeprom instead of .bin.

Sorry, I don't see how this makes any difference. The code you posted simply doesn't work like this (the propeller tool uses .binary for upload). Adding sufficient stack space is the minimum requirement here (see AN019).

Vega256 · 2011-06-13 18:57

kuroneko wrote: »

Sorry, I don't see how this makes any difference. The code you posted simply doesn't work like this (the propeller tool uses .binary for upload). Adding sufficient stack space is the minimum requirement here (see AN019).

When my code is compiled, the compiled file is read by my programmer. Apparently, binary file format isn't being interpreted correctly by my programmer but eeprom files are. My code didn't work because what was on the eeprom wasn't a valid program.

StefanL38 · 2011-06-13 21:37

I have a question,
why do you use uploading *.bin or *.EEPROM files at all?

Is there a particular reason why you don't just hit F11 in the propellertool to make the propellertool do five things automatically in sequence ?

1.) compile your code
2.) download into propeller-RAM
3.) verifying RAM
4.) download into EEPROM
5.) verifying EEPROM

best regards

Stefan

Vega256 · 2011-06-14 05:33

StefanL38 wrote: »

I have a question,
why do you use uploading *.bin or *.EEPROM files at all?

Is there a particular reason why you don't just hit F11 in the propellertool to make the propellertool do five things automatically in sequence ?

1.) compile your code
2.) download into propeller-RAM
3.) verifying RAM
4.) download into EEPROM
5.) verifying EEPROM

best regards

Stefan

Because my Propeller is not connected to my computer. I did not set the circuit up this way.

1.) I compile the code
2.) save the compiled code as an .eeprom file
3.) upload the .eeprom file to my eeprom programmer
4.) burn the .eeprom file into my eeprom
5.) insert the eeprom in my circuit
6.) run the Propeller

Dave Hein · 2011-06-14 06:56

Vega256, kuroneko has a valid point that your program has a problem if you don't increase the size of the stack. The program that you posted probably looks like it's running OK, but I suspect it is not writing a value of 10 to the four output pins. I think the byte variable "data" is being overwritten by the stack frame when you do the cognew. Your cog 0 program exits immediately after doing the cognew, so it doesn't write to its stack after that. If cog 0 were to continue to run it would be using the same area of memory for its stack, and it would interact with cog 1's stack. You really need to increase the size of cog 1's stack.

StefanL38 · 2011-06-14 09:27

cheapest way to upload the code to the propeller directly into the EEPROM is using the attached circuit.

It is taken from page 5 of the datasheet of the propeller.

You simply connect pin 30,31 and reset to pin 11 to the circuit and you are done.

You just need a serial port or an USB-Serial-adapter.
Make sure the USB-adapter uses an FTDI-chip that you can use the tested FTDI-driver

best regards

Stefan

Cognew - I really should know this by now...

Comments