Completely baffled

Paul M

Here's a piece of code of no practical use but it demonstrates the problem:
·

CON
  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000

OBJ
  term  : "FullDuplexSerial"
   sn   : "Simple_Numbers"
VAR
  LONG  param
  
PUB Main | rx_p,tx_p,r 
delay(3000)
rx_p:=31  
tx_p:=30  
r:=term.start(rx_p,tx_p,0,19200)   'use program port as debug port 
term.str(string("Hello",13,10))
 
param:=23
 
term.dec(param)
'term.str(sn.dec(param))       'substituting either of these
'term.str(sn.decf(param,4))    'calls causes unexpected results
 
term.str(string(13,10))
 
cognew(@entry,@PARAM)

 
delay(200)
term.str(string("Returned",13,10))
 
term.dec(param)
'term.str(sn.dec(param))      'substituting either of these   
'term.str(sn.decf(param,4))   'calls causes unexpected results
 
PRI Delay (ms)
waitcnt(ms*80_000+cnt)
 
DAT
entry   mov foo,#147
        wrlong foo,par
foo res 1          

As written the result is as expected.

If the term.dec(param) call is replaced with either of those that use the Simple_Numbers.spin object I get unexpected results.
However,·if the·assembly routine is not run (cognew(..) line·commented out) the·result is as expected whether or not the Simple_Number functions·are used.
I'm sure it is something obvious but I just can't see it - can someone please enlighten me?

Paul

Nick Mueller

The missing ORG?


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Jasper_M

How about killing the cog when it's done? ie.

  cogid foo
  cogstop foo

before foo?

Paul M

Nick, Jasper
The code runs as expected when I don't make any calls to the Simple_Numbers object but just to be sure I've inserted ORG 0 and no difference.
The results seem to depend on which function and when it·is called in the Simple_Numbers·object,some examples:

Expected output using 'term.dec(param)' :
Hello
23
Returned
147

Output using 'term.str(sn.decf(param,4))' :
Hello
· 23
Èeturned
·147

Output using 'term.dec(param)' before the call to cognew and 'term.str(sn.decf(param,4))'·after:
Hello
23
Retur 147

Note that the results are repeatable and not a comms problem.

I've just tried this:

'term.dec(param)
term.str(sn.dec(param))       'substituting either of these
'term.str(sn.decf(param,4))    'calls causes unexpected results
term.str(string(13,10))
 
cognew(@entry,@PARAM)

 
delay(200)
term.str(string("Returned",13,10))
 
term.dec(param)
'term.str(sn.dec(param))      'substituting either of these   
term.str(sn.decf(param,4))   'calls causes unexpected results
 

which gives:
Hello
23
Returned
3·· 00011

Help!

dfletch

Could it be those (13,10)'s?

I don't know squat about the FullDuplexSerial term, but when I tried this with the VGA term, the "10", ($A) is used to position the cursor horizontally - so the fist char of the next string is treated as the argument of the "move cursor" command. Just removing the "10"s made it work fine on VGA.

Cheers,

--fletch

deSilva

Paul,
when you do not follows Jasper's advice this COG of yours will do the most undefined things. It is no use of looking into anything before you make it "defined", either by an endless loop, or by stopping it!

hippy

Best to always have an endless loop rather than letting it run wild and hoping to stop the cog IMO.

There's no guarantee what the code will have done before it's stopped whilst it executes whatever garbage got dragged in with the PASM. The call to stop the cog could have been corrupted before it even gets a chance to execute.

Paul M

Hippy, deSilva

I was just composing a reply to deSilva when·your post (Hippy)·arrived, to say that I had tried stopping the cog and this didn't work. Including an endless loop does work as you say.

Having re-read the posts I relaise that I didn't read Jasper's post carefully; his suggestion was to stop the cog inside the assembly routine and this does of course work.

I did understand from deSilva's tutorial(which I have read several times) that·a cog is loaded with 512 bytes·by a cognew(..) but I had not appreciated that the cog just continues executing instructions after the last line of the assembly routine - obvious that it does when one thinks about it, otherwise if the interpreter knew where the end of the routine was it would only load the relevant data(?)

deSilva, a description of this·behaviour would be very useful in your tutorial if you have the inclination to update it.

·I am still very green when it comes to assembly and the prop but all your helpful replies have yet again increased my understanding.

Thanks

deSilva

Oh dear... an update... It's NEARLY ready since Christmas... I remember i promised to post it BEFORE the C compiler arrives.. Let's see

Loading COGs/running COG code. As you say, Paul, it is obvious that the COG does not know where to stop. This is different with SPIN... a SPIN main program always stops efter the last line, thaks to intelligence of the compiler. If you had lived in the early 60th you would have used FORTRAN, where you had to include a STOP line at the end, otherwise funny things would have happened on some machines....

Note that the loading of a COG is a BASIC HARDWARE FEATURE, which has limited intelligence. And as was nicely explained in another thread some hours ago. ASSEMBLY coding is just doing all by yourself...